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REMARKS 

Applicant has withdrav^n the pending application from Appeal and filed a Request for 
Continued Examination. This communication is responsive to the Advisory Action mailed July 
22, 2005. In this response, Applicant has amended claims 1 , 2 1 , 30, 3 1 , 40 and 43 and canceled 
claim 29. Claims 1-28 and 30-43 are pending upon entry of this amendment. 

Claim Rejections Under 35 V.S.C. SS 102. 103 

In the Final Office Action, the Examiner rejected claims 1-15, 17-18, 21-25, 29-43 under 
35 U.S.C. 102(e) as being anticipated by Moussa et al. (USPN 6,742,03) in view of eekim.com 
(CGI Programming slides, 1996 (hererin, "Eeikim"). In addition, the Examiner rejected claims 
16, 19-20, 26-28 under 35 U.S.C. 103(a) as being tmpatentable over Moussa et al. Applicants 
respectfully traverse the rejection. Moussa et al. (Moussa) in view of Eekim fails to disclose 
each and every feature of the claimed invention, as required by 35 U.S.C. 102(e), and provides 
no teaching that would have suggested the desirability of modification to include such features, 
as required by 35 U.S.C. 103. 

For purposes of clarification, Applicants have amended claim 1 to include the 
requirement of sending a pre-determined m essage to initiate a page rendering process at the 
remote client, wherein content of the message is the same regardless of the requested web 
resource . In this manner, Applicants have clarified that message is pre-determined and, 
therefore, does not change based on the requested resource. Support can be found throughout the 
present specification. For example, pg. 7, 11.7-9 states that, in some embodiments, the Initial 
Page Rendering (IPR) message is generic such that the same IPR message is sent each time the 
server receives a request. As another example, the Summary of the present application states 
that the IPR may be a predetermined application level message adapted to initiate a page 
rendering process. Other clarifying claim amendments have been made to claims 21, 30, 3 1 and 
43. 

Moussa in view of Eekim fails to teach or suggest receiving a request for a web resource 
from a remote client and, prior to processing the request, sending a predetermined message to 
initiate a page rendering process at the remote client. Moreover, Moussa in view of Eekim fails 
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to teach or suggest sending a predetermined message that is the same regardless of the requested 
web resource. 

Moussa describes a proxy server that reformats web content in a particular way under 
certain conditions as determined by the operator of the proxy server.^ The proxy server retrieves 
web content requested by a client, reformats it into a suitable format for the requesting client, and 
then forwards the reformatted web content to the requesting client. 

With respect to Moussa, the Examiner primarily relies on col. In. 35-65, which reads as 
follows: 

HTML rewriter software 11 also functions to reduce or eliminate a dead time 
(^'perceived latency**) sometimes experienced by a user of client 2, The browser in client 2 
can start to render a web page involving an image if the browser has size information for 
the image. If the browser has size information for the image, then the browser can begin 
to lay out the background page leaving a blank of the appropriate size for the image data 
yet to arrive, ...To avoid this perceived latency at the client, WebTV server 6 stores size 
information relating to the image in cache 8. When client 2 requests a web page 
involving an image, WebTV server 6 retrieves the size information from its cache, 
rewrites the HTML of the web page to include the size information, and then relays the 
HTML on to client 2. The browser in client 2 can therefore begin to render the web page 
using the size information for any images on the web page when it receives the HTML for 
the background page. The browser does not have to wait until it deciphers the HTML of 
the background page, identifies the image tag, issues a request for the image data 
identified by the image tag, and receives the actual image data with the size information. 
The size information is received along with the original HTML, The result of the 
rewriting of the HTML therefore results in a reduction in ^'perceived latency'* at client 2, 

The Examiner also relies on col. 10. 11. 45-60, which similarly states: 

To eliminate this "perceived latency** in the rendering of the background 
page, tokenizer CRM 403 inserts the size information into the HTML before the 
HTML is passed back to client 102. 

The Examiner's argument can be best understood by viewing the Advisory Action mailed 

July 22, 2005. In the Advisory Action, the Examiner referred to Moussa and stated: 

fWJhat is requested isn V the metadata but the actual content. The client would 
first request a page/image, the server side initially sends the size information of the 
requested data to allow for initial rendering of the webpage contents on the client side, 
not that the actual requested contents have not yet arrived. Thus the message returned is 
independent of the request. 
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^ Thus^m rejecting Applicants' claims, the Examiner is arguing that the image size information 
^^?^^nied by the Moussa proxy server is independent of the request in that the image size 

information is not the actual requested content. However, the image size information returned by 
Moussa is directly a function of the particular image requested by the client. As quoted above, 
Moussa makes very clear that, when client 2 requests a web page involving an image, WebTV 
server 6 retrieves the size information for that particular image from its cache, rewrites the 
HTML of the web page to include the size information, and then relays the HTML on to client 2. 

Thus, Moussa makes clear that, for a given client request, the request must be processed 
to first determine the requested image, and then size information for that particular image is 
returned to the client to reduce latency. If the client requests a different image, then different 
image size information is returned. Moreover, Moussa specifically states that the image size 
information is inserted into the HTMLof the requested web page that is retumed to the client. 

For these reasons, Moussa fails to teach or suggest any form of initial page rendering 
message that is "pre-determined," as required by Applicants' claim 1 as amended. The size 
information retumed by the Moussa proxy server is not a pre-determined message. To the 
contrary, the size information depends entirely on the particular page/image that is requested. 

For at least these reasons, Moussa also fails to teach or suggest an IPR message where 
content of the message is the same regardless of the requested web resource. Clearly the size 
information returned by Moussa varies depending on the particular page/image requested by the 
client device. 

Eekim adds nothing to address the deficiencies of Moussa. As discussed above, Eekim 
merely describes the format of a standard HTTP response itself includes as including a header 
that instructs the browser as to the type of content carried by the remainder of that same 
response, which is of course not "pre-determined" and changes depending upon the particular 
requested web resource. 
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CONCLUSION 

All claims in this application are in condition for allowance. Applicants respectfully 
request reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit accoimt number 50-1 778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 

Date: 

SHUMAKER «& SIEFFERT, P.A. 
8425 Seasons Parkway, Suite 105 
St. Paul, Minnesota 55125 
Telephone: 651.735.1100 
Facsimile: 651.735.1102 



By: 

wit T Qipffi^rt / f 



Name: Kent J. Siefifert 
Reg. No.: 41,312 
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